[Top] [Prev] [Next] [Bottom]
[Contents]
Overview
Using the Browser
The way many systems store state is to send the information that must be remembered down to the browser along with the HTML code. The arrangement is then that the HTML passes all that information back up to the server side with the next use of an activator.
There are some potential problems with this way of implementing state:
Sending information to the browser along with HTML code remains a popular technique because it is simple to understand and easy to implement. Another advantage of storing state on the browser is that it does not consume server resources.
Sapphire/Web provides a State Server. This service program operates as a repository for data so that the concept of state and persistence over time can be added to the essentially stateless Web. This is used to implement the Shopping Cart demonstration available on the Bluestone Web Site.
The Sapphire/Web State Server retains pieces of information provided to it by server applications and refers to them by a number (generated by the State Server). This number can then, of course, be used by the program in order to retrieve the stored information later.
To do this, however, implies that the program accessing the State Server will know what number to use; not necessarily a fact when one is using a server application that exits after each and every operation. Therefore the numbers obtained from the State Server can be held by the browser in much the same way as in the section above.
There are also some potential problems here:
On the other hand, the data is proof against casual snooping, as only references to it are available to the browser user.
With version 3.0, Bluestone has enlarged the user's access from Sapphire/Web projects to the State Server. New API calls allow one-line storage and retrieval of server-side cookies using the State Server. This option is now much easier to implement. In addition, all data passed from server to browser and back is encrypted as default to protect the transactions being supported.
The information being passed to and from the browser can be either HTTP cookies or Sapphire/Web cookie numbers.
Perhaps the ultimate in state retention is the use of Client Objects. With appropriately-written Java or ActiveX components, you can retrieve information from a site and then process it entirely off-line, retaining all considerations of state within an especially-written program entirely local to your PC. When finished, the user can re-link to the Web Server and present the altered data once again for acceptance back into the database.
In this case all state is held locally within the programs running on the user's machine. This means that the user is in complete control of the state situation at all times.
The only downside to this approach is that a larger amount of programming has to be initially invested in order to write the Java or ActiveX components used and to arrange for users to be able to reserve records in a database (if database update is required).
The positive benefits accruing from this approach, on the other hand, also include the ability to launch programs native to the client machine and have them process the data retrieved from the net. Not all programmers need to become experts in Java or ActiveX Web programming!
[Top] [Prev] [Next] [Bottom]
[Contents]
info@bluestone.com
Copyright © 1997, Bluestone. All rights
reserved.